Conversation
added 3 commits
April 22, 2026 15:52
…rComment, junctions, Okr base table)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OKR Purge Logic Explanation
OKR entities are not scope-specific — none of them have a
ScopeID. However, since we doom Members that are assigned only to doomed Scopes, we must cascade into OKR assets owned or authored by those doomed Members. Additionally, we must clean up many-to-many junction tables where either side of the relation is doomed.Rack 'em Phase (Identification)
OwnerIDis a required FK to Member. When a Member is doomed, their OkrObjectives become orphaned — they cannot exist without an owner.OkrObjectiveIDis a required FK. Once an OkrObjective is doomed, its KeyResults become orphaned — they cannot exist without their parent objective.OkrComment has two required FKs:
BelongsToID(to Okr) andAuthorID(to Member). Both are NOT NULL. If the parent Okr is doomed, the comment cannot exist. If the authoring Member is doomed, the comment also cannot exist. Either required FK being orphaned means the entity must be doomed.Whack 'em Phase (Deletion)
OkrAssociatedAssets is a many-to-many junction linking Okrs to BaseAssets. When either side of the relation is doomed, the junction row is invalid and must be removed. We only remove the relation — we do NOT doom an Okr just because it is associated to a doomed BaseAsset.
OkrObjectiveSharedAccessWith is a many-to-many junction for shared access between OkrObjectives and Members. When either side is doomed, the junction row is invalid and must be removed.
OkrObjectiveLinkedFrom is a many-to-many self-referencing junction between OkrObjectives. If either linked objective is doomed, the link is invalid and must be removed.
OkrComments are removed by doomed ID. No nulling of
AuthorIDis needed because it is required (NOT NULL), and all comments with a doomed author were already doomed in the Rack 'em phase.KeyResults are removed by doomed ID.
OkrObjectives are removed by doomed ID.
CascadedFromIDis an optional self-reference — a surviving objective could cascade from a doomed one, so it is nulled to avoid a dangling FK.Okr is the base table that OkrObjective and KeyResult inherit from. After the derived type rows are deleted, the base Okr rows must also be removed. This goes last because children must be deleted before parents.